<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic
  PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<topic id="db-segment">
   <title> segment_* </title>
   <body>
      <p>The <codeph>segment_*</codeph> tables contain memory allocation statistics for the
         Greenplum Database segment instances. This tracks the amount of memory consumed by all
         postgres processes of a particular segment instance, and the remaining amount of memory
         available to a segment as per the settings configured by the currently active resource management scheme (resource group-based or resource queue-based).
         See the <cite>Greenplum Database Administrator Guide</cite> for more
         information about resource management schemes.</p>
      <p>There are three segment tables, all having the same columns:</p>
      <ul>
         <li>
            <codeph>segment_now</codeph> is an external table whose data files are stored in
               <codeph>$MASTER_DATA_DIRECTORY/gpperfmon/data</codeph>. Current memory allocation
            data is stored in <codeph>segment_now</codeph> during the period between data collection
            from the <codeph>gpperfmon</codeph> agents and automatic commitment to the segment_history
            table.</li>
         <li>
            <codeph>segment_tail</codeph> is an external table whose data files are stored in
               <codeph>$MASTER_DATA_DIRECTORY/gpperfmon/data</codeph>. This is a transitional table
            for memory allocation data that has been cleared from <codeph>segment_now</codeph> but
            has not yet been committed to <codeph>segment_history</codeph>. It typically only
            contains a few minutes worth of data.</li>
         <li>
            <codeph>segment_history</codeph> is a regular table that stores historical memory
            allocation metrics. It is pre-partitioned into monthly partitions. Partitions are
            automatically added in two month increments as needed. </li>
      </ul>
      <p>A particular segment instance is identified by its <codeph>hostname</codeph> and
            <codeph>dbid</codeph> (the unique segment identifier as per the
            <codeph>gp_segment_configuration</codeph> system catalog table).</p>
      <table>
         <tgroup cols="2">
            <thead>
               <row>
                  <entry>Column</entry>
                  <entry>Type</entry>
                  <entry>Description</entry>
               </row>
            </thead>
            <tbody>
               <row>
                  <entry>
                     <codeph>ctime</codeph>
                  </entry>
                  <entry>
                     <p>timestamp(0)</p>
                     <p>(without time zone)</p>
                  </entry>
                  <entry>The time the row was created.</entry>
               </row>
               <row>
                  <entry>
                     <codeph>dbid</codeph>
                  </entry>
                  <entry>int</entry>
                  <entry>The segment ID (<codeph>dbid</codeph> from
                        <codeph>gp_segment_configuration</codeph>).</entry>
               </row>
               <row>
                  <entry>
                     <codeph>hostname</codeph>
                  </entry>
                  <entry>charvar(64)</entry>
                  <entry>The segment hostname.</entry>
               </row>
               <row>
                  <entry>
                     <codeph>dynamic_memory_used</codeph>
                  </entry>
                  <entry>bigint</entry>
                  <entry>The amount of dynamic memory (in bytes) allocated to query processes
                     running on this segment.</entry>
               </row>
               <row>
                  <entry>
                     <codeph>dynamic_memory_available</codeph>
                  </entry>
                  <entry>bigint</entry>
                  <entry>The amount of additional dynamic memory (in bytes) that the segment can
                     request before reaching the limit set by the currently active
                     resource management scheme (resource group-based or resource queue-based). </entry>
               </row>
            </tbody>
         </tgroup>
      </table>
      <p>See also the views <codeph>memory_info</codeph> and <codeph>dynamic_memory_info</codeph>
         for aggregated memory allocation and utilization by host.</p>
   </body>
</topic>
